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Verfahren zur Koordination von Netzwerkkomponenten 
STAND DER TECHNIK 

Die vorliegende Erfindung betrifft ein Verfahren zur Ko- 
ordination bzw. Abstimmung von Netzwerkkomponenten, ins- 
besondere Master- und Slavekomponenten, wobei mindestens 
eine erste logische Komponente und eine zweite logische 
Komponente vorgesehen sind, welche jeweils einer bestimm- 
ten Applikation entsprechen und uber das Netzwerk auf ei- 
ner von der Applikationsebene im wesentlichen unabhangi- 
gen Kommunikationsebene miteinander kommunizieren konnen. 

Die Erfindung ist fur weite Bereiche der Kommunikations- 
technik anwendbar, sie wird jedoch beispielshalber nur in 
bezug auf ein CAN-Netzwerksystem bei Anwendung im KFZ-Be- 
reich naher erlautert. 

Bei solchen, in einem KFZ installierten Systemen ergibt 
sich oftmals die Situation, dafi nur einzelne Komponenten 
des Netzwerksys terns nach einem Fehlerfall einen Neustart, 
d.h. Reset, durchf tihren . Ein typischer Ausloser ftir einen 
solchen Reset ist die Erkennung einer Unterspannungsbe- 
dingung # die von Komponente zu Komponente variieren kann. 

Hieraus resultiert das grundsatzliche Problem, spezielle 
Kommunikationsmechanismen zwischen den Komponenten zu de- 
f inieren, um moglichst schnell ein Wiederauf setzen der 
verteilten Applikationen zu erreichen. Hierbei ist es im 
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allgemeinen vorteilhaft, den Zustand des Gesamt systems 
vor dem Reset - soweit moglich - wieder zu reproduzieren 
bzw. abzustimmen. Von besonderer Bedeutung ist dies fur 
Systeme mit Benutzerinteraktion, beispielsweise uber ein 
5 Anzeige- und Bedienteil, urn durch Resets ausgeloste Sto- 
rungen im Bedienablauf , wie etwa nicht mehr aktuelle Dar- 
stellungen auf einem Display, Zeitverzogerungen bei der 
Bedienung von Komponenten, verlorengegangene Eingaben 
etc . zu minimieren . 



Die der vorliegenden Erfindung zugrunde liegende Proble- 
matik besteht also allgemein darin, in einem Netzwerk mit 
verteilten Applikationen die den Applikationen entspre- 
chenden Ne t z wer kkomponent en auf ef fektive Weise zu koor- 
dinieren. Dies gilt insbesondere fur einen Neustart nach 
einem Fehlerfall von einzelnen Komponenten . 

Generell miissen die folgenden vier Falle erkannt und an- 
gemessen behandelt werden . 



i) "Normales" Hochfahren aller Komponenten (System- 



ii) zeitgleicher Fehler aller Komponenten nach System- 
start, z. B. durch Unterspannung fur alle Komponen- 
ten im Netzwerk, 




t 10 



20 



start) , 



iii) Fehler eines Teilsystems nach Systems tart, d. h. 

Fehlerbedingung einer oder mehrerer Komponenten, und 
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iv) Hardware-Reset nach erstmaligem Einschalten (First 
Power-On) oder fatalem Fehler. 

Zunachst wird die spezielle Problematik einer gegenseiti 
gen Koordination bzw. Synchronisation von verteilten Ap- 
plikationen und deren diesen entsprechenden logischen 
Komponenten naher erlautert . 

In Systemen, in denen Komponenten miteinander iiber ein 
Netzwerk, beispielsweise ein Bussystem, kommunizieren, 
ist eine gewisse Grundvoraussetzung fur das hier be- 
schriebene Verf ahren eine Trennung von Kommunikation und 
Applikation innerhalb einer Komponente (s. ISO 7498, In- 
formation processing systems - Open systems Intercon- 
nection Basic Reference Model, 1984) . 

Betrachtet werden hier Systeme, die iiber ein Netzwerk, 
z.B. ein Bussystem, kommunizieren, wobei Kommunikation 
und Applikation f olgendermaSen definiert sind. 

Unter die Kommunikation fallen alle Funktionen, die zum 
gesicherten Datenaustausch mit anderen Komponenten beno- 
tigt werden. Typischerweise findet eine aus dem OSI- 
Modell der ISO <s.o.) abgeleitete Schichtung der Kommuni 
kation Verwendung, d. h. eine Umsetzung von der physika- 
lischen Schicht bis zur Applikationsschnittstelle . Den 
Anf orderungen dieses Verwendungsgebietes angepaSt wird 
fur den KFZ-Bereich in den gangigen Losungen nur eine Un 
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termenge des OSI-Modells eingesetzt, d.h. einige Schich- 
ten bleiben "leer". Weiterhin wird in Erweiterung des 
OSI-Modells ublicherweise ein die verschiedenen Schichten 
umfassendes Netzmanagement eingesetzt, welches die unter- 
schiedlicHen Komponenten hinsichtlich der Koitimunikation 
synchronisiert . 

Unter Applikation wird die spezifische Aufgabe jeder Kom- 
ponente verstanden, z. B. die Funktionalitat eines CD- 
Spielers oder die verschiedenen Funktionen eines Autote- 
lef ons . 

In Systemen, die uber logische Punkt-zu-Punkt ( 1 : 1 ) -Ver- 
bindungen zwischen den einzelnen Komponenten verfiigen, 
werden uber eine solche Verbindung die "Kommandos" der 
Applikation einer Komponente A an die Komponente B wei- 
tergeleitet, die diese dann z. B. mit einer Applikations- 
Ruckmeldung beantwortet . Ein Beispiel ist.die Aktivierung 
eines CD-Changers zum Spielen durch ein Bedienteil. 

ZweckmaSigerweise werden diese 1 : 1 Verbindungen der Ap- 
plikationsebene auf die 1:1 Verbindungen der Transport- 
schicht (Schicht 4 im OSI-Modell) abgebildet. Wahrend die 
1 : 1-Transportverbindungen von beiden beteiligten Kompo- 
nenten aufgebaut bzw. im Fehlerfall zuruckgesetzt werden 
konnen, was einem syitunetrischen Verhalten entspricht, 
gilt dies nicht fur die Applikationsebene . Hier ist bei- 
spielsweise nur eine Komponente A - der "Master" - be- 
rechtigt, eine Komponente B - den "Slave" - zu steuern. 
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Insbesondere trifft dies fur das Schalten der Hauptzu- 
stande des Slaves zu,*wie z. B. "EIN" und "AUS" . 

Zweckmafiigerweise liegt einem solchen System ein Netzma- 
nagement zugrunde, das ebenfalls zwischen Master- und 
Slave-Funktionalitat unterscheidet . In diesem Fall ist 
normalerweise ein „Applikations-Master w auch gleichzeitig 
ein „Netzmanagement-Master" . Daneben sind allerdings auch 
durchaus Systeme denkbar, die beim Netzmanagement nur 
gleichberechtigte Stationen kennen, bei denen demnach die 
Master- /Slave-Unterscheidung auf die Applikationsebene 
beschrankt ist. Ein typisches Beispiel fur letztgenanntes 
Netzmanagement-Verfahren ist unter dem Namen „dezentrales 
Netzmanagement" auf CAN-Netzen im Karosseriebereich der 
KFZ- Indus trie zu finden. 

Sofern nicht ausdrucklich anders aufgefiihrt, bezieht sich 
daher im folgenden die Bezeichnung ^Master" bzw. „Slave M 
immer auf die Applikationsebene. 

Ein relativ einfaches System besteht demnach aus einem 
Master und einem oder mehreren Slaves, mit jeweils einer 
1:1 Verbindung zwischen Master und jedem Slave. Aller- 
dings konnen auch komplexere Systeme, bestehend aus meh- 
reren Masterkomponenten mit denselben oder auch unter- 
schiedlichen Slaves, gebildet werden. Voraussetzung ist 
hierbei nur, dafi fur jede logische Verbindung eindeutig 
festgelegt ist, welche Komponente Master und welche -Slave 
ist. Auf diese Weise laSt sich dann ein hierarchisches 
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System aus Master, Submaster ( s ) und Slaves bilden, wie in 
der alteren Anmeldung^DE 196 373 12 beschrieben. 

Ublicherweise ist fur eine Koordination der netzweiten 
Applikationen in erster Linie der Master verantwortlich. 
Fur den Slave reicht es aus, den Reset eines Masters bei- 
spielsweise uber einen Netzmanagementdienst zu erkennen. 

Dies fuhrt beispielsweise beim Slave zum Einleiten be- 
stimmter Notlauf f unktionen oder auch zum selbstandigen 
Herunter f ahren . 

Der Master erkennt den Reset einer Slave-Komponente ent- 
weder durch zyklisches Abfragen des Slave-Status oder 
durch einen erneuten Kommunikationsaufbau, eingeleitet 
durch den Slave (z.B. Kommunikationssystem mit Netzmana- 
gement und Transportprotokoll nach den alteren Anmeldun- 
gen DE 41 31 133 bzw. DE 196 373 12). 

Als nachteilhaft bei dem obigen bekannten Ansatz hat sich 
die Tatsache herausgestellt , dafi das zyklische Abfragen 
des Slave-Status durch den Master aufwendig und kommuni- 
kationsint'ensiv ist, da meist keine Anderung des Status 
vorliegt. Des weiteren ist dies.er Abf ragemechani smus in- 
flexibel, da im allgemeinen nur bereits installierte Kom- 
ponenten abgefragt werden. 

SchlieSlich bringt ein erneuter Kommunikationsaufbau 
durch den Slave als Alternative zu dem obigen zyklischen 
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Abf ragemechanismus den Nachteil mit sich, da£ der Master 
auSer der Information? dafi die Kommunikation wieder zu- 
standegekommen ist, keine Mitteilungen liber die Ursache 
des Resets und/oder dessen Vorgeschichte, namlich bei- 
spielsweise den vorherigen Applikationsstatus erhalt. 

Die Art des eigenen Resets kann vom Master erkannt wer- 
den, z.B. durch Eintrag von eigenen Statusinf ormationen 
in einen nichtf luchtigen Speicher, wie beispielsweise ei- 
nem EE PROM, und durch Auswertung des Eintrags bei einem 
nachf olgenden Neustart. 

Findet der Master z.B. den Eintrag "System gestartet und 
in Normalbetrieb" nach einem Reset vor, so kann er auf 
einen Neustart durch eine Fehlerbedingung schlieSen . Ist 
dagegen "System heruntergef ahren" eingetragen, so handelt 
es sich urn ein normales Hochf ahren. Problematisch ist im 
Fehlerfall die begrenzte Speichermoglichkeit im Master. 

Im allgemeinen kann nur der eigene Status gesichert wer- 
den, da fur die Zustandsspeicherung aller angeschlossener 
Slaves die Zeit und/oder die Speicherkapazitat normaler- 
weise nicht ausreicht. Darliber hinaus ist ein Ruckgriff 
auf beispielsweise in einem EE PROM abgespeicherte Status- 
inf ormationen uber den Slave speziell beim Fehler-Reset 
des Masters risikoreich, da ja auch der Slave einen Reset 
durchgefuhrt haben konnte und damit der gespeicherte Sla- 
ve-Zustand vom aktuellen Zustand abweicht. 
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Da in den obigen Standardlosungen keine detaillierten 
bzw. gesicherten Status-Inf ormationen liber den Slave vor- 
liegen, wird der Master im allgemeinen die Slave- 
5 Applikation neu starten, bzw. initialisieren . 

Da hierdurch im allgemeinen vorherige Einstellungen zu- 
riickgesetzt werden mtissen, bedeutet dies den Verlust des 
Wissens um die Vorgeschichte des Slaves, d.h. der ur- 
J|K 10 sprungliche Betriebszustand oder Status der Applikation 
ist nxcht mehr ableitbar. Aus dem Neustart der Slave- 
Applikation resultieren im allgemeinen merkliche Verzoge- 
rungen . 



15 VORTEILE DER ERFINDUNG 



0- 



Das erf indungsgemaSe Verfahren mit den Merkmalen des An- 
spruchs 1 weist gegenuber dem bekannten Losungsansatz den 
Vorteil auf, dafi es den alten Applikationszustand (Appli- 
20 kationsstatus) , beispielsweise eines Slaves, vor Auftre- 
ten eines Fehlers an beliebiger Stelle im Netzwerk effi- 
zient wiederherstellen kann. 



Dadurch wird es beispielsweise ermoglicht, gegebenenf alls 
25 nur lokal an dem betroffenen Slave einen Reset durchzu- 
fiihren, der von dem Benutzer des Systems -beispielsweise 
einem Autofahrer - nicht wahrgenornmen wird, da ein globa- 
les Reset ausbleiben kann . 
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Durch das gezielte Wi£der-Auf setzen eines kurzzeitig aus- 
gefallenen Slaves ergibt sich im allgemeinen ein Zeitvor- 
teil gegenuber ublichen Losungen, bei denen alle lauf en- 
den Applikationen neu initialisiert werden miissen. Weiter 
ergeben sich zusatzliche Moglichkeiten fur eine netzweite 
Diagnose . 

GemaS der Erfindung ist durch die Ubermittlung der Vorge- 
schichte, vorzugsweise in Verbindung mit einer Netzwerk- 
zustandstabelle in dem Master, auch ein sicheres Erkennen 
von neuen Komponenten im Netz ohne groSen Konf igurations- 
aufwand fur den Master moglich. Da in der erf indungsgema- 
Sen Inf ormat ionsnachr icht , die im folgenden auch als 
Start-up-Info bezeichnet wird, zweckmafiigerweise mitge- 
teilt wird, ob eine Komponente zum ersten Mai am Netzbe- 
trieb teilnimmt, kann der Master entsprechend reagieren, 
z.B. durch das Freischalten von neuen Bedienmeniis . 

Auch ermoglicht das erf indungsgemaSe Verfahren die Ver- 
riegelung von Applikationen in bestimmten Zustanden, 
falls mehr als ein Master auf einen Slave zugreift. Dies 
gilt insbesondere fur den Fall, daS ein Master den Slave 
in einen Diagnosemodus gebracht hat. In diesem Fall ist 
der Slave im allgemeinen nicht mehr von einem weiteren 
Master steuerbar. Dies ist fur diesen Master ebenfalls 
aus der Start-up-Info z.B. nach einem Reset unmittelbar 
ersichtlich. Die Start-up-Info ist daneben grundsatzlich 
fur die Ubermittlung von sogenannten Seimaphoren, die 
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wichtig fur die Synchronisation von verteilten Applika- 
tionen bzw. von ProzeSsen im DV-technischen Sinne sind, 
geeignet. 



5 Die der vorliegenden Erfindung zugrundeliegende Idee be- 
steht darin, das Wiederauf setzen auf Applikationsebene 
durch den bzw. die Master unter Beriicksichtigung des ak- 
tuell gemeldeten Applikationsstatus durchzuf uhren, indem 
der bzw. die Slaves ihren aktuellen Status in einem Spei- 
-f!^ 10 cher sichern, nach einer Anderung jeweils wieder aktuali- 
sieren und nach bestinunten Ereignissen, beispielsweise 
einem Fehler in der Sphare des Slaves, eine Start-up-Info 
an den Master senden. 

15 Hierbei wird als Ausloser letzterer Nachricht der erfolg- 
reiche Aufbau der 1 : 1-Verbindung zwischen Master und Sla- 
ve verwendet. Als vom Master ausgehende Trigger fur die- 
sen Verbindungsaufbau konnen wiederum zumeinen bestimmte 
Netzmanagement-Mechanismen wie bestimmte Netzmanagement- 
20 Telegramme, im folgenden auch als Watchdog-Telegramme be- 
^ zeichnet, oder aber auch z.B. eine vom Master gesteuerte 

t Schaltleitung Verwendung finden. 

Weiterhin kann dieser Trigger auch im Slave begrundet 
25 liegen. Ein typisches Beispiel bildet das Aufwecken eines 
Netzwerks durch eine Telef onkomponente . In diesem Fall 
geht die Initiative zum Verbindungsaufbau allein vom Sla- 
ve aus . 



R. 32543 



- 11 - 



In den Unteranspriichen finden sich vorteilhafte Weiter- 
bildungen und Verbesserungen des in Anspruch 1 angegebe- 
nen Verfahrens. 

GemaS einer bevorzugten Weiterbildung werden die Informa- 
tionen der ubermittelten Inf ormationsnachricht in der er- 
sten logischen Komponente in dem nicht-f luchtigen Spei- 
cher gespeichert. 

GemaS einer weiteren bevorzugten Weiterbildung verwendet 
die erste logische Komponente die Inf ormationen der uber- 
mittelten Inf ormationsnachricht zur Rekonstruktion des 
Zustands vor dem Aufbauen der Kommunikationsverbindung . 

GemaS einer weiteren bevorzugten Weiterbildung enthalt 
die Inf ormationsnachricht Inf ormationen beziiglich der 
Initiative zum Aufbauen der Kommunikationsverbindung. 

GemaS einer weiteren bevorzugten Weiterbildung stehen die 
erste und die zweite logischen Komponente in einer Ma- 
ster-Slave-Beziehung zueinander. 

GemaS einer weiteren bevorzugten Weiterbildung wird die 
Inf ormationsnachricht nach einem Reset bei bereits ge- 
starteter Applikation mindestens einer der ersten oder 
der zweiten logischen Komponente ubermittelt. 
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GemaS einer weiteren bevorzugten Weiterbildung enthalt 
die Inf ormationsnachricht Inf ormationen daruber, ob die 
zweite Komponente einen Hardware-Reset durchgefiihrt hat. 

5 GemaS einer weiteren bevorzugten Weiterbildung werden be- 
stimmte Inf ormationen, die Inhalt der Inf ormationsnach- 
richt werden, in einem nichtf luchtigen Speicher der zwei- 
ten logischen Komponente gespeichert. 

^ 10 GemaS einer weiteren bevorzugten Weiterbildung wird der 
Inhalt des nichtf luchtigen Speichers der zweiten logi- 
schen Komponente jedesmal dann aktualisiert , wenn eine 
Anderung des Applikationsstatus der zweiten logischen 
Komponente eintritt. 

15 

GemaS einer weiteren bevorzugten Weiterbildung enthalt 
die Inf ormationsnachricht weitere Inf ormationen zur Vor- 
geschichte der zweiten Komponente. 

20 Besonders bevorzugte Anwendungen des erf indungsgemaiSen 

Verfahrens liegen in Mefi- und/oder Uberwachungssystemen, 
f in KFZ-Boardinf ormationssystemen und in netzwerkweiter 

Fehlerortung und/oder Fehlerdiagnose von Netzwerkkompo- 
nenten solcher Systeme. 

25 
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ZEICHNUNGEN 

Ausfiihrungsbeispiele der Erfindung sind in den Zeichnun- 
gen dargestellt und in der nachf olgenden Beschreibung na- 
her erlautert. 

Es zeigen: 

eine schematische Darstellung der gemaS einer 
ersten Ausf iihrungsf orm am erf indungsgemaSen 
Verfahren beteiligten Netzwerkkomponenten , nam- 
lich einen Master, der mit einem Slave verbun- 
den ist. 

den zeitlichen Verlauf des erf indungsgemaSen 
Verfahrens gemafi der ersten Ausf iihrungsf orm 
zeitlich von oben nach unten f ortschreitend bei 
einem Reset des Slaves in Folge einer Unter- 
spannung . 

BESCHREIBUNG DER AUSFUHRUNGSBEISPIELE 

Fig. 1 zeigt eine schematische Darstellung der gemaS ei- 
ner ersten Ausf iihrungsf orm am erf indungsgemaSen Verfahren 
beteiligten Netzwerkkomponenten, namlich einen Master, 
der mit einem Slave verbunden ist. 

In Fig. 1 bezeichnet Bezugszeichen 1 ein Radio, 2 einen 
CD-Changer, 3 eine Kommunikationsverbindung zwischen dem 



Fig. 1 



Fig. 2 
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Radio 1 und dem CD-Changer 2 sowie 4 und 5 jeweils nicht- 
fluchtige Speicher. 

Das relativ einfache System enthalt das Radio 1 als Ma- 
ster und den angeschlossenen CD-Changer 2 als Slave des 
Radios 1 und eine die beiden Netzwerkkomponenten 1, 2 
miteinander verbindende Kommunikationsverbindung 3 in 
Form einer Busleitung. Weiter verfugen sowohl das Radio 1 
als auch der CD-Changer 2 iiber nichtf liichtige, Speicher 4 
bzw. 5, die beispielsweise in Form von gepufferten SRAMs 
oder EEPROMs realisiert sein konnten. Die Speicher 4, 5 
dienen der Speicherung von Daten, deren Auswertung durch 
den Master 1 zur Koordination der Netzwerkkomponenten 1, 
2 dienen . 

Figur 2 zeigt schematisch den zeitlichen Verlauf des er- 
f indungsgemaSen Verfahrens gemaS der ersten Ausfuhrungs- 
form zeitlich von oben nach unten f ortschreitend bei ei- 
nem Reset des Slaves in Folge einer Unterspannung . 

In Fig. 2 bezeichnet 6 ein Watchdog-Telegramm, d.h. eine 
Aufforderung des Radios 1 an den CD-Changer 2, eine Kom- 
munikation aufzubauen bzw. auf rechtzuerhalten. 

Die linke auEere Linie stellt die Applikationsschnitt- 
stelle 1A des Radios 1 dar, die zweite Linie von links 
die Kommunikationsschnittstelle IK des Radios 1 , die 
dritte Linie von links die Kommunikationsschnittstelle 2K 
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des CD-Changers 2 und die rechte auSere Linie die Appli- 
kationsschnittstelle 2A des CD-Changers 2 . 

Anfangs und in der Figur oberhalb von ti ist das System 
initialisiert und beide Komponenten, das Radio 1 und der 
CD-Changer 2, sind in Betrieb. Im CD-Changer 2 ist dessen 
Status, beispielsweise „ PLAY w , in dem nichtf luchtigen 
Speicher 5 gespeichert. Vom Radio 1 werden zyklisch 
Watchdog-Telegramme 6 an den CD-Changer 2 gesendet . 

Zum Zeitpunkt ti selbst tritt eine Betriebsstdrung, hier 
eine Unterspannung im CD-Changer 2 auf, die einen Reset 
des CD-Changers 2 notig macht .. Sobald diese Unterspannung 
als solche erkannt ist, werden neben dem bereits gespei- 
cherten gegenwartigen Applikationszustand „PLAY" des CD- 
Changers 2 erwunschte weitere Inf ormationen liber seine 
Vorgeschichte, z.B. „Fehler im Slave" sowie die letzte 
Position des CD-Abtas tsys terns , in seinem nicht-f luchtigen 
Speicher 5 gespeichert. 

Dazu sei erganzend erlautert, dafi bei Auftreten einer Un- 
terspannung bei einer Komponente die Versorgungsspannung 
i.a. nicht auf Null Volt heruntergeht . Grund dafur ist 
eine Pufferung der Versorgungsspannung. Bei leichten Un- 
terspannungen konnen bestimmte Mafinahmen zur Sicherung 
aktueller Daten in den nicht-f ltichtigen Speicher (soweit 
vorhanden) eingeleitet werden. Damit verbunden sind nor- 
malerweise ein Zuriicksetzen der Applikation und/oder der 
Kommunikation (z.B. Abbau logischer Verbindungen) . Steigt 
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die Spannung wieder an, so mussen Applikation sowie ggfs. 
Kommunikation neu initialisiert werden ( „ Warms tart n ) . 

Dabei bedeutet Initialisierung der Applikation eine Vor- 
bereitung der Applikation und ggfs. einen Start der Ap- 
plikation (i.a. kein selbstandiger Applikationsstart bei 
einem Slave) . Initialisierung der Kommunikation bedeutet 
das Tref fen von Vorbereitungen fur die Kommunikation mit 
anderen Netzwerkkomponenten, z.B. einen Verbindungsauf - 
bau . 

Erst wenn die Versorgungs spannung unter einen kritischen 
Wert sinkt droht ein Hardware -Reset des Mikrocontrollers 
sowie der Verlust aller Daten im fliichtigen Speicher 
(RAM) . Nach einem Hardware-Reset muS die Komponente einen 
sogenannten „Kaltstart w durchfuhren, bei dem i.a. eine 
spezielle Initialisierungsroutine durchlaufen werden mufi. 
Solch eine Grundinitialisierung betrifft die Komponente 
auf der untersten Ebene, z.B. Setzen/Zuriicksetzen von (LLC- 
Ports usw. Wird in dieser Routine beispielsweise ein Flag 
im RAM gesetzt, besteht die Moglichkeit, einen Kaltstart 
(Verlust aller Daten, wenn kein nicht-f luchtiger Speicher 
zur Verfiigung steht) von einem Warms tart (Teilverlust von 
Daten) zu unterscheiden . Der Begriff Reset ist im folgen- 
den also nicht zwangslaufig mit einem Hardware-Reset des 
Mikrocontrollers gleichzusetzen . 
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Der CD-Changer 2 erhalt nun bei t 2 ein Watchdog-Telegramm 
6 vom Radio 1 und baut daraufhin die Verbindung zum Radio 
1 wieder auf . 

Bei t 3 quittiert das Radio 1 dem CD-Changer 2 den Verbin- 
dung s auf bau . Hiermit verbunden ist eine Reinitialisierung 
der Kommunikationsverbindung im Radio 1. 

Bei t 4 sendet der CD-Changer 2 daraufhin die Informati- 
onsnachricht, die Start-Up-Inf o, an das Radio 1. Das Ra- 
dio 1 verarbeitet diese Inf ormationsnachricht und sendet 
inf olgedessen bei t 5 geeignete Applikationsnachrichten 
zur Wiederherstellung des alten Zustands vor dem Auftre- 
ten der Unterspannung an den CD-Changer 2, beispielsweise 
die Befehle "Einschalten" und "Play" . Somit ist der Zu- 
stand wiederhergestellt, in dem das System vor Eintritt 
der betriebsstorenden Unterspannung war. 

Zur Begriindung fur den hier beschriebenen Ablauf sei be- 
merkt, dafi es im Regelfall nicht sinnvoll ist, dafi der 
Slave versucht, selbstandig seinen alten Zustand komplett 
zu restaurieren . Hintergrund ist, daS auch im Master 
(oder in einer anderen, hier nicht gezeigten Komponente) 
ein Fehler aufgetreten sein kann, so dafi die verschiede- 
nen Applikationen nicht mehr synchronisiert sind. Bei- 
spielsweise wurde es keinen Sinn ergeben, wenn der CD- 
Changer selbstandig seinen alten Zustand „ PLAY" restau- 
rieren wurde, das Radio aber aufgrund eines internen Re- 
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sets die Audio-Signale des CD-Changers nicht mehr verar- 
beiten wurde. 

Der wesentliche Inhalt der Inf ormationsnachricht "Start- 
up Info" ist der aktuelle Applikationszustand des CD- 
Changers 2 bzw. des Slaves, soweit er fur die Bedienung 
des CD-Changers 2 aus Sicht des Radios 1 bzw. des Masiters 
von Bedeutung ist. Bedeutsame Applikationshauptzustande 
aus Sicht dieses Masters sind beispielsweise EIN/AUS, 
d.h. sie zeigen dem Radio 1 an, ob die Slave-Applikation 
fur den Master verfiigbar ist oder nicht. 

Es konnen jedoch auch andere, spezielle Applikat ions zu- 
stande aktiviert gewesen und dementsprechend nun dem Ma- 
ster angezeigt werden, wie beispielsweise die Wiedergabe 
eines CD-Changers (PLAY) im vorliegenden Ausf iihrungsbei- 
spiel oder etwa ein Diagnose-Modus . 

Weitere spezielle Zustande des Slaves konnen kennzeich- 
nen, daS der Slave nur einen eingeschrarikten Funktionsum- 
fang besitzt, da beispielsweise die Applikationssof tware 
noch von einer CD-ROM geladen werden muE oder weil eine 
Verriegelung des Slaves seitens anderer logischer Verbin- 
dungen besteht, wie oben bereits erwahnt wurde. 

Desgleichen konnen diverse Zustande der Mensch-Maschine- 
Schnittstelle des Slave, also beispielsweise Menus oder 
Fenster auf einem Bildschirm, die aktuelle Belegung von 
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Softkeys im System, dem Master auf eine solche Weise an- 
gezeigt werden. 

Ein optionaler Bestandteil ist der sogenannte Initiali- 
sierungsanstoS. Dies ist ein Bestandteil, der angibt, wer 
letztlich den Aufbau der Kommunikationsverbindung initi- 
iert hat . 

Dieser AnstoS kann sowohl im Master als auch im Slave be- 
grundet liegen. Im ersten Fall, der den Normal fall dar- 
stellt und dem obigen Beispiel zugrunde liegt, liefert 
der Master den Initialisierungsanstofi, z.B. durch einen 
Netzmanagement-Mechanismus in Form eines Watchdog- 
Tel egamms . Ein Beispiel fur den zweiten Fall bildet das 
Wecken durch einen Slave, welches beispielsweise durch 
die Verbindungsaufbautelegramme des Slaves ausgelost 
wird. Aufgrund der ubermittelten Information „Initiali- 
sierungsanstoS durch Slave" kann der Master im letzteren 
Fall den unerwarteten Verbindungs aufbau durch den Slave 
leicht als Wecken interpretieren und von Fehlerfallen un- 
terscheiden . 

Ein weiterer optionaler Bestandteil beschreibt die Vorge- 
schichte der Applikation. In diesem Fall wurde die Sit- 
zung durch einen Fehler beendet, es kam zu einem Reset 
der Kommunikation sowie der Applikation wegen des Auftre- 
tens einer Unterspannung des CD-Changers 2 . Daher hat der 
Bestandteil die Bedeutung "Fehler im Slave" und kann 
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durch ein Flag oder ein anderes Kennzeichen signalisiert 
werden . 

Wenn in einem anderen Fall die Applikation bei der letz- 
ten Sitzung, d.h. dem letzten zusammenhangendem Zeitraum 
mit einer giiltigen 1 : 1-Verbindung zwischen Radio 1 und 
CD-Changer 2 beispielsweise durch einen Ausschaltbef ehl 
ordnungsgemaS verlassen wurde, konnte der Inhalt des Be- 
standteils die Bedeutung "o.k." haben. 

Befindet sich der CD-Changer 2 zum ersten Mai am Netz, 
dann konnte der Inhalt des Bestandteils die Bedeutung 
"NEU" haben. Ein solches Kennzeichen ist wichtig fur eine 
Grundinitialisierung nach einem Austausch, einem Neuein- 
bau oder zur Diagnose nach einem f atalen Fehler . 

Bei der Ubermittlung der Vorgeschichte ist zu beachten, 
daS die Start-up- Info ausschliefilich die Sicht des Slaves 
widerspiegelt . Erst ein Vergleich mit den im Master ge- 
speicherten Daten erlaubt eine endgiiltige Aussage zur 
Vorgeschichte des Systems . 

Generell gilt nun, daS nur in der Komponente, die einen 
Reset wahrend des Betriebs durchfiihrt, Applikation und 
Kommunikation gleichermafien initialisiert werden. In der 
verbundenen Komponente, hier dem Radio 1 als Master, wird 
dagegen nur ein Reset der Kommunikation ausgeftihrt. Der 
Reset ist notig, urn die 1 : 1-Kommunikationsverbindung wie- 
der zu synchronisieren . Die Applikation des Masters ist 
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normalerweise nicht unmittelbar vom Reset der anderen 
Komponente betroffen. v 

Eine Initialisierung der Kommunikation ist also auch ohne 
eine Initialisierung der Applikation moglich. Bei einer 
1 : 1-Verbindung erfolgt ini Fehlerfall ein Reset der Kommu- 
nikationsschichten also auf beiden Seiten, wahrend die 
Applikation beispielsweise nur auf einer Seite zuriickge- 
setzt wird. 



Das Verfahren beruht also auf einer automatischen Meldung 
des Slaves an den Master, die den aktuellen Zustand der 
Slave -Komponente sowie deren Vorgeschichte en thai t, ini- 
tiiert durch ein spezielles, eindeutiges Kommunikations- 
15 erereignis. Dieses kann ausgelost sein durch das Auftre- 
ten der Unterspannung am CD-Changer 2 bzw. durch den Re- 
set des CD-Changers 2 . 

Aufgrund aller Start-up- Inf ormationen der angeschlossenen 
2 0 Slaves sowie der eigenen, im nichtf liichtigen Speicher 4 
des Masters enthaltenen Daten kann der Master 1 nun sehr 
effizient den alten Applikationszustand nach einem Fehler 
rekonstruieren . 

2 5 Meldet eine Komponente abweichend vom Ausf iihrungsbei- 
spiel, daS sie neu im Netz ist, so zeigt ein Vergleich 
mit den gespeicherten Daten des Masters, ob diese Kompo- 
nente einen Fehler, beispielsweise eine extreme Unter- 
spannung, einen fatalen Sof twaref ehler oder dgl . hatte, 
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was beispielsweise wichtig fur eine Systemdiagnose ware, 
oder ob sie wirklich fteu im Netz ist. In diesem Fall 
konnte ein spezieller Konf igurationslauf erfolgen, der in 
einem Ausf uhrungsbeispiel weiter unten erlautert wird. 

Zusammenf assend ermoglicht das erf indungsgeniaSe Verfahren 
gemafi diesem Ausf uhrungsbeispiel also eine ereignisorien- 
tierte Merk- oder Speicherf unktion der Komponenten und 
enthalt folgende Mechanismen. 



Ein Slave sendet automatisch jedem ihm zugeordneten Ma- 
ster uninittelbar nach dem erf olgreichen (Wieder- ) Aufbau 
der 1:1 Verbindung zum Master als erste Applikationsnach- 
richt eine spezielle Inf ormationsnachricht mit Statusin- 
15 formationen ( " Start-Up-Inf o" ) in den folgenden Fallen: 

nach erfolgter eigener Initialisierung bzw. eigenem 
Reset der Koiranunikationsschichten und 

20 - nach erfolgtem Reset der Kommunikationsschichten durch 
den Master. 

Dabei ist zu bedenken, daS grundsatzlich beide - Master 
oder Slave - unabhangig von ihrer hierarchischen Einbet- 
25 tung in das Gesamtsystem des Netzwerks die gegenseitige 
Kommunikation beginnen konnen . 



R. 32543 



- 23 - 



Da die Vorgeschichte anhand der Start-Up Infos der Slaves 
vom Master abgeleitet" werden kann, ergeben sich zusatzli- 
che Moglichkeiten fur eine netzweite Diagnose. 

5 Im folgenden zweiten Ausf tihrungsbeispiel sei ein wei teres 
System angenommen, das aus einer beliebigen Master- und 
zwei und in einer weiter unten beschriebenen Abwandlung 
drei beliebigen Slave-Komponenten besteht. 

^ 10 Zunachst bef inden sich neben dem Master zwei weitere Kom- 
ponenten A, C - Slaves des Masters - im Netzwerk. Eine 
weitere Komponente B ist dem Master zwar bekannt, sie ist 
jedoch (noch) nicht angeschlossen . 

15 Das erf indungsgemaSe Verfahren laSt sich fur dieses Sy- 
stem auch in Anlehnung an Fig. 2 beschreiben. 

Es wird eine in dem nicht fliichtigen Speicher des Masters 
abgelegte Netzwerkstatustabelle mit Konf igurations- , Ver- 
20 bindungs- und Applikationszustanden der bekannten Slaves 




exemplarisch gezeigt . 
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Bekannte Slaves 


Netz-- 

konf iguration 


Verbindung s - 
status 


Applikat ions- 
status 


Komponente A 


"vorhanden" 


"Verbindung 
auf gebaut " 


"Applikation 
ein" 


Komponente B 


"nicht verfiig- 
bar" 


"keine Verbin- 
dung " 


"nicht verfiig- 
bar" 


Komponente C 


" vorhanden " 


"Verbindung 
auf gebaut " 


"Applikation 
aus " 



Die Netzwerkstatustabelle wurde zum Zwecke einer besseren 
Verstandlichkeit so einfach wie moglich gehalten. Norma - 
lerweise enthalt eine solche Tabelle weitaus mehr Infor- 
mationen, z. B. Konf igurationsdaten fur die einzelnen 
Verbindungen . 

Aus Ubersichtsgriinden nennt dieses Beispiel nur die Ap- 
plikationshauptzustande "EIN" und "AUS" bzw. "nicht ver- 
fiigbar" . Neben den Informationen in dieser Netzwerkzu- 
standstabelle speichert der Master auch seine eigene Vor- 
geschichte. 

In einer Abwandlung des letztgenannten Beispiels (Neu- 
anschluS eines Slaves) erhalt der Master nach einem Ver- 
bindungsauf bau folgende "Start-up Info" von der Komponen- 
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B an Master: "B zum ersten Mai im Netz, Applikationszu- 
stand , AUS' " . 

Der Master kann aufgrund dieser Information einen spezi- 
ellen Konf igurationslauf starten. Die Netzwerkstatusta- 
belle andert sich dann wie folgt: 



Bekann t e SI ave s 


Netz- 


Verbindungs - 


Applikations- 




konf iguration 


status 


status 


Komponente A 


"vorhanden " 


" Verbindung 
auf gebaut " 


" App 1 i ka t i on 
ein" 


Komponente B 


" vorhanden" 


" Verbindung 
auf gebaut " 


"Applikation 
aus " 


Komponente C 


"vorhanden" 


"Verbindung 
auf gebaut " 


"Applikation 
aus " 



Von diesem Zeitpunkt an ist der Master in der Lage, die 
Applikation der Komponente B zu starten und alle verflig- 
baren Funktionen zu steuern. 

Im folgenden wird ein beispielhaf ter Fehlerfall darge- 
stellt . 

In einer weiteren Veranderung des letztgenannten System- 
zustands erhalt der Master nach erneutem Verbindungs auf- 
bau der Komponenten A und C folgende "Start-up Informa- 
tionen" : 
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A an Master: "A war bSreits im Netz, Applikation ; AUS' H . 

C an Master: "C ist zum ersten Mai im Netz, Applikation 
, AUS 

Nach Vergleich mit den gespeicherten Inf ormationen kann 
der Master nun unmittelbar den alten Zustand durch ge- 
zielte Applikationsnachrichten wieder rekonstruieren (in 
diesem einfachen Beispiel ist nur eine Nachricht notwen- 
dig) : 

Master an A: "Applikation , EIN'" . 

Weiterhin kann der Master feststellen, daS Komponente A 
einen " Warms tart " und Komponente C sogar einen "Kalt- 
start" durchgefiihrt hatte, da Komponente C im Netz be- 
reits vorhanden war. Diese Daten konnen mit speziellen 
Fehlerzahlern verwaltet und uber Diagnosesof tware ausge- 
wertet werden. 

Obwohl die vorliegende Erfindung vorstehend anhand bevor 
zugter Ausf iihrungsbeispiele beschrieben wurde, ist sie 
darauf nicht beschrankt, sondern auf vielfaltige Weise 
modif izierbar . 

So kann das erf indungsgemaSe Verfahren auch fur komplexe 
re Systeme eingesetzt werden, in denen der Master eines 
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oder mehrerer Slaves wiederum der Slave eines Masters auf 
einer ranghoheren Ebefie ist. 

Ebenso ist es einsetzbar in Systemen, in denen ein oder 
mehrere Slaves mehr als nur einem Master zugeordnet sind. 

Ebenso kann das erf indungsgemaSe Verfahren in Netzwerken 
mit Client-Server-Architekturen verwendet werden, wobei 
i.a. der Client eine gewisse Masterfunktionalitat iiber- 
nimmt . 

Desweiteren ist es prinzipiell in Uberwachungs- und Feh- 
lerdiagnosesystemen in beliebigen technischen, vernetzten 
Einrichtungen einsetzbar. Insbesondere im KFZ-Bereich er» 
geben sich dabei vielfaltige Anwendungsmoglichkeiten bei 
der Fehleruberwachung und Fehlerdiagnose von vernetzten 
elektronischen Steuergeraten . 

Ebenso konnen die Kommunikationsverbindungen zwischen den 
Komponenten durch drahtlose Verbindungen realisiert sein. 
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Verfahren zur Koordination von Netzwerkkomponenten 
PATENT ANS PRUCHE 

1. Verfahren zur Koordination von Netzwerkkomponenten 
(1, 2) , wobei mindestens eine erste logische Kompo- 
nente (1) und eine zweite logische Komponente (2) 
vorgesehen sind, welche jeweils einer bestimmten Ap- 
plikation entsprechen und liber das Netzwerk auf ei- 
ner von der Applikationsebene im wesentlichen unab- 
hangigen Kommunikationsebene miteinander kommunizie- 
ren konnen, mit den Schritten: 

Aufbauen einer Kommunikationsverbindung zwischen der 
ersten und der zweiten logischen Komponente (1, 2) 
auf Initiative einer der ersten oder zweiten logi- 
schen Komponente (1, 2) ansprechend auf ein bestimm- 
tes Ereignis, welches die erste und/oder zweite lo- 
gische Komponente (1, 2) betrifft; 

Ubermitteln einer Inf ormationsnachricht iiber die 
aufgebaute Kommunikationsverbindung von der zweiten 
logischen Komponente (2) an die erste logische Kom- 
ponente (1) , wobei die Inf ormationsnachricht zumin- 
dest Inf ormationen bezuglich des aktuellen Applika- 
tionsstatus der zweiten logischen Komponente ent- 
halt; und 



Vergleichen der Inf ormationen der iibermittelten In- 
f ormationsnachricht in der ersten logischen Kompo- 
nente (1) mit dort in einem nicht-f luchtigen Spei- 
cher (4) gespeicherten entsprechenden Inf ormationen . 

Verfahren nach Anspruch 1, dadurch gekennzeichnet, 
daS die Inf ormationen der iibermittelten Informati- 
onsnachricht in der ersten logischen Komponente (1) 
in dem nicht-f luchtigen Speicher (4) gespeichert 
we r den . 

Verfahren nach Anspruch 1 oder 2 , dadurch gekenn- 
zeichnet, daS die erste logische Komponente (1) die 
Inf ormationen der iibermittelten Inf ormationsnach- 
richt zur Rekonstruktion des Zustands vor dem Auf- 
bauen der Kommunikationsverbindung verwendet . 

Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet , dafi die Inf ormationsnach- 
richt Inf ormationen bezuglich der Initiative zum 
Aufbauen der Kommunikationsverbindung enthalt. 

Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, dafi die erste und die zweite 
logischen Komponente (1, 2) in einer Master-Slave- 
Beziehung zueinander stehen. 
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Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet , date die Inf ormationsnach- 
richt nach einem Reset bei bereits gestarteter Ap- 
plikation mindestens einer der ersten oder der zwei 
ten logischen Komponente (1, 2) tibermittelt wird. 

Verfahren nach Anspruch 6, dadurch gekennzeichnet, 
daS die Inf ormationsnachricht Inf ormationen daruber 
enthalt, ob die zweite Komponente (2) einen Hard- 
ware-Reset durchgefuhrt hat. 

Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, daS bestimmte Inf ormationen 
die Inhalt der Inf ormationsnachricht werden, in ei- 
nem nichtf liichtigen Speicher (5) der zweiten logi- 
schen Komponente (2) gespeichert werden. 

Verfahren nach Anspruch 8, gekennzeichnet durch den 
Schritt, daS der Inhalt des nichtf liichtigen Spei- 
chers (5) der zweiten logischen Komponente (2) je- 
desmal dann aktualisiert wird, wenn eine Anderung 
des Applikationsstatus der zweiten logischen Kompo- 
nente (2) eintritt. 

Verfahren nach Anspruch 8 oder 9, dadurch gekenn- 
zeichnet, daS die Inf ormationsnachricht weitere In- 
f ormationen zur Vorgeschichte der zweiten Komponent 
(2) enthalt. 
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11. Durchflihrung des - Verf ahrens nach einem der vorste- 
henden Anspruche in einem hierarchisch aufgebauten 
System von Netzwerkkomponenten, von denen die erste 

5 logische Komponente (1) fur eine oder mehrere zweite 

logische Komponenten (2) eine Masterf unktion ausiibt. 

12. Durchfiihrung des Verfahrens nach Anspruch 11 in ei- 
nem hierarchisch aufgebauten System von Netzwerkkom- 

10 ponenten, von denen die zweite logische Komponente 

(2) fur eine oder mehrere erste oder zweite logische 
Komponenten (1, 2) eine Masterf unktion ausubt . 

13 . Anwendung des Verfahrens nach einem der vorstehenden 
15 Anspruche in MeS- und/oder Uberwachungssystemen 

und/oder Steuerungssystemen in der Fertigungstech- 
nik. 

14 . Anwendung des Verfahrens nach einem der vorstehenden 
2 0 Anspruche in KFZ-Bordinf ormationssystemen . 

15 . Anwendung des Verfahrens nach einem der vorstehenden 
Anspruche zur netzwerkweiten Fehlerortung und/oder 
Fehlerdiagnose von Netzwerkkomponenten (1,2). 

25 
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Verfahren zur Koordination von Netzwerkkomponenten 
ZUSAMMENFASSUNG 

5 

Es wird ein Verfahren zur Koordination von Netzwerkkompo- 
nenten (1, 2) vorgeschlagen, wobei mindestens eine erste 
logische Komponente (1) und eine zweite logische Kompo- 
nente (2) vorgesehen sind, welche jeweils einer bestimm- 

10 ten Applikation entsprechen und iiber das Netzwerk auf ei- 
ner von der Applikationsebene im wesentlichen unabhangi- 
gen Kommunikationsebene miteinander kommunizieren konnen, 
mit den Schritten: Aufbauen einer Kommunikationsverbin- 
dung zwischen der ersten und der zweiten logischen Kompo- 

15 nente (1, 2) auf Initiative einer der ersten oder zweiten 
logischen Komponente (1, 2) ansprechend auf ein bestimm- 
tes Ereignis, welches die erste und/oder zweite logische 
Komponente (1, 2) betrifft; Ubermitteln einer Informati- 
onsnachricht liber die aufgebaute Kommunikationsverbindung 

2 0 von der zweiten logischen Komponente (2) an die erste lo- 
gische Komponente (1) , wobei die Inf ormationsnachricht 
zumindest Inf ormationen bezuglich des aktuellen Applika- 
tionsstatus der zweiten logischen Komponente enthalt; und 
Vergleichen der Inf ormationen der iibermittelten Informa- 

25 tionsnachricht in der ersten logischen Komponente (1) mit 
dort in einem nicht-f luchtigen Speicher (4) gespeicherten 
entsprechenden Inf ormationen . 



(Fig. 1) 
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Verfahren zur Koordination von Netzwerkkomponenten 



BEZUGSZEICHENLISTE 



1 


erste, logische Komponente, Master 
(Radio) 


2 


zweite logische Komponente, Slave (CD- 
Changer ) 


3 


Kommunikationsverbindung 


4 


nicht f liicht iger Spe icher 


5 


vorzugsweise nichtf luchtiger Speicher 


6 


Watchdog -Telegrainm 
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